|
|
|
|
|
|
|
Revisiting Use Cases in Your Environment |
|
|
|
|
|
|
|
|
For many newcomers to object-oriented programming, the cyclical and sometimes chaotic nature of object technologyand projects that implement such technologycan be frustrating. The expression iterative incremental development sounds appealing and has become a popular catch phrase in the software development industry. However, when you do iterative incremental development, the process is often frustrating and sometimes seemingly stuck in analysis paralysis or design demise. Some describe the iterative incremental development experience as resembling the movie Groundhog Day (the movie's star Bill Murray keeps waking up on the same day, having the same nightmarish experiences). |
|
|
|
|
|
|
|
|
After you've practiced the iterative development approach often enough, it's really not that bad. In fact, iterative development isn't exclusively object-oriented; it's just that object technology has capitalized on the best practices of preceding development methods. The most experienced developers who don't use object technology have done some form of iterative development. What we've learned in the last half century of software development is that new discoveries about the problems we are trying to solve will occur throughout the entire life cycle of a project. If the discovery is important enough, you must resolve it with analysis and design activities before implementing the new requirement. Therefore, revisiting use cases should become natural to you as you develop your Visual Basic applications. |
|
|
|
|
|
|
|
|
Project managers who are more comfortable with other methodologies shun any notions of making and resolving key discoveries too often. In such cases, you should seek an approach that comes across as controlled, in which discoveries are resolved according to a prioritization plan. A project that looks chaotic (which is characteristic of any software development project) will typically involve managers in technical minutiae more than is necessary and healthy. Before revisiting any use case, then, you should have some kind of iteration plan in place. |
|
|
|
|
|
|
|
|
New Term: An iteration plan captures the project activities you and your team members must perform, as well as delivery of the artifacts that result from these activities. |
|
|
|
|
|
|
|
|
Although you can certainly create an iteration plan at any time during your project, you should definitely have one a few weeks before you begin actual code construction. This is because an iteration plan can be pegged with scheduled dates for deliverables from analysts, designers, programmers, and testers. However, these dates, as well as the iterations in the iteration plan, aren't going to be reasonably well-known until you're in the middle of designing the low-level details of the solution your application represents. Therefore, attempting to force an iteration plan to be static before any detail design |
|
|
|
|
|